perf: sharded OnceTable - #225

[P1] Drop entries when they are discarded

HashIndex::remove_if_sync only marks an entry unreachable and explicitly permits its memory to be reclaimed later. Because ReadyEntry owns a strong Arc<Entry<K, V>>, removing the entry from the shard does not release its key or value. The following integration test fails on this head with left: 0, right: 1, while it passes against 0.6.7:

#[test]
fn discard_drops_the_removed_value() {
    use std::sync::Arc;
    use std::sync::atomic::{AtomicUsize, Ordering};

    use asyncband::once::OnceMap;

    #[derive(Clone)]
    struct DropCounter(Arc<AtomicUsize>);

    impl Drop for DropCounter {
        fn drop(&mut self) {
            self.0.fetch_add(1, Ordering::SeqCst);
        }
    }

    let drops = Arc::new(AtomicUsize::new(0));
    let map: OnceMap<_, _> =
        [(0, DropCounter(Arc::clone(&drops)))].into_iter().collect();

    map.discard(&0);

    assert_eq!(drops.load(Ordering::SeqCst), 1);
}

This is the documented reclamation behavior of HashIndex::remove_if_sync, but it is observable here because the deferred index entry owns the map's key and value transitively. Under insert/discard churn, resources can accumulate until the index collector—or the whole OnceMap—is dropped. Please avoid retaining a strong Arc in the deferred-reclamation index, or otherwise ensure that strong ownership is released before discard returns.

[P2] Bound or expose the eager shard allocation

Eager CPU-scaled sharding has precedent, but this exact default is unusually aggressive for OnceMap and especially singleflight::Group. DashMap uses available_parallelism * 4, eagerly creates its shards, and exposes with_shard_amount constructors so callers can trade contention for footprint. The canonical Go singleflight implementation instead lazily initializes one mutex-protected map, and scc::HashIndex, already used by this PR, starts with zero capacity.

This implementation uses available_parallelism * 8 with no override. On this 14-way host that becomes 128 #[repr(align(64))] shards. An allocator probe measured:

• OnceMap::new() and Group::new(): 1 allocation / 8,192 bytes, versus 0 allocations in 0.6.7.
• OnceMap::with_capacity(1): 132 allocations / 14,592 bytes, versus 1 allocation / 44 bytes in 0.6.7.

On the 32-core machine used to choose the coefficient, every empty instance starts with 256 shards and at least 16 KiB of cache-line-padded storage. The throughput results establish the benefit for a hot shared table, but do not cover construction or workloads containing many empty/small maps and groups.

Could we add construction/allocation benchmarks and either expose an explicit shard-count constructor with a more conservative or capped default, or allocate shard storage lazily? The sharding optimization itself is justified; the concern is making its most aggressive configuration an unavoidable per-instance cost.